The following steps provide a basic guideline for the Darwin Scheduler work flow.

1. Build and create an EPS (Extended Period Simulation) model of the hydraulic network of interest.
2. Calibrate the model.
3. Start Darwin Scheduler and create a new Scheduler Study.
4. Identify the pumps or pump stations (with a preference for pump stations) that will be optimized by Scheduler.
5. Identify the hydraulic performance criteria that must be maintained (hydraulic constraints).
6. Identify the objective elements that should be included in the calculation of the objective function (energy use or energy cost). It is possible for a pump or pump station to be included in the calculation of the objective function but not be optimized. For example, a pump that is always on need not be optimized but the costs can be included in the objective function.
7. Specify the objective type (either minimize energy use or minimize energy cost).
8. Create a new Optimized Run.
9. Select whether pumps will be optimized as fixed speed or variable speed, their allowable speed settings (if variable speed), whether pumps are allowed to be turned off (if variable speed) and also whether the pumps are optimized for the entire EPS or a portion of it. Note that if optimizing only a portion of the EPS (for any one pump decision) Scheduler turns off pumps outside of the portion of the schedule being optimized. For example, for a 24 hour EPS run a pump decision that is set for a time from start of 12 hours and duration of 12 hours will be off from time 0 to time <12, and optimized for time 12 to time <24. The pump will be off at time 24 to ensure a repeatable schedule).
10. Select which objective elements to include in the optimization objective function (by default all included in the study are selected).
11. Choose which genetic algorithm you wish to use and adjust any required parameters (see a later FAQ for information on these settings).
12. Run the optimized run.
13. Optionally stop the optimized run mid flight and review results and resume the run if results are favorable. To do this, select the Stop button in the progress dialog. After reviewing the run, the run can be restarted by picking the compute button and selecting Resume or started from the beginning by picking Compute. Closing Scheduler or performing any other function that runs a pressure computation (such as calculating another scenario) will terminate the paused scheduler run.
14. When the optimized run is complete, review summary results in Darwin Scheduler and choose solutions to export. If any results look promising, choose the solutions to export, else repeat steps k through m with different genetic algorithm parameters. Two prime examples would be population size (try larger perhaps) and random seed (try a different seed).
15. Export the chosen solutions to a new scenario by picking the Export to Scenario button on the top of the left pane.
16. Run the exported scenarios.
17. Run an energy costs analysis.
18. View and analyze the optimized schedule results.
19. Make any tweaks or adjustments to the optimized solution as appropriate, noting that due to the nature of the optimization algorithm sometimes Scheduler will turn off one pump only to turn an equivalent pump on; what the optimization is really saying in this case is that 1 pump of type x should be running.

As alluded to in step n above, it should be noted that the steps from the point of setting up the Scheduler study to exporting solutions and reviewing results can be performed in an iterative loop with adjustments made to the Darwin Scheduler input based on the results of the first set of optimization runs, aimed at improving or re-directing the next set of optimized run results. This is in fact the recommended work flow for using Darwin Scheduler.

Darwin Scheduler uses a control interval defined by the hydraulic time-step of the EPS being optimized. This is done since to apply a change in pump setting/status a new steady state simulation is required and so it makes the most sense to align this with the hydraulic time step. To this end, you can reduce the number of pump decisions the optimization needs to make by increasing the hydraulic time step say from 1 hour to 2 hours or 2 hours to 3 hours. Any intermediate time steps that need to be simulated (such as for tanks filling or controls triggering) will still be simulated as per normal EPS protocol.

We've built no hard limits into Scheduler to prevent it from being used with very large hydraulic models, with very fine control intervals or with lots of pump decisions, however, the performance of Darwin Scheduler in terms of both run time and also optimization results is dependent on the user applying reasonable engineering judgment to minimize the complexity of the problem to be solved and also ensuring the model upon which the optimization is based runs as fast as possible.

Consider an EPS mode that takes 10 seconds to solve and factor in that for a reasonable sized solution space it may take 100,000 trial solutions to achieve a near global optimum. The computer time needed to evaluate 100,000 trial solutions is 1,000,000 seconds or 278 hours, or 11.5 days. Most people will probably not want to run optimization runs that last 11.5 days so there needs to be an appreciation that the time needed for the optimization is a function of the time to solve the model. There are a number of ways that the run time for a model can be reduced, but the main one is skeletonization, which if done correctly (such as using hydraulic equivalent skeletonization) can reduce run time significantly whilst having little or no effect on system hydraulics nor upon the results of an energy optimization.

The other side of the equation in terms of optimization performance is the number of trials required to reach a near global optimum. We've used 100,000 trials above as a reasonable number of trials, but depending on the size of the solution space (the complexity of the optimization problem) it may be more than this figure and it could also be less. The solution space is defined as the total number of combinations of possible solutions. So for the case of pump optimization it is the total possible combination of pump speed settings over the course of the optimization. See the Darwin Scheduler Best Practices and Tips topic for more information about keeping the solution space to a minimum.

This is a feature of Darwin Scheduler and is to allow one to assess the difference in running pumps (any pumps) as fixed speed versus variable speed without first having to modify the pump type in the model. If for example it is decided that a pump that is currently fixed speed can achieve significant operational improvements by being operated as variable speed then it may be decided to replace the existing pump with a variable speed pump.

In Scheduler, a pump should be viewed in one and only one way in a given run.

1. As a single pump; each pump is treated individually and is not aware that it is part of a station and which pumps are in the station with it.
2. As part of a station; Scheduler does not consider exactly which identical pumps are running but merely keeps track of the number of identical pumps running.

Treating pumps as part of a station is win-win since it reduces the problem dimensionality and avoids un-necessary pump switches that may occur when treating pumps as individual optimization decisions. This will usually result in faster runs with better optimal solutions. However, if all the pumps in a station are different, then the results between treating the pumps individually or as part of the station will not be any different.

For Variable Speed Pump Battery elements, Scheduler optimizes the pump speed and number of running lag pumps as independent optimization decisions. To that end if the pump speed is 0.0 the solution considers all lag pumps to be off too, so the lead-lag relationship is maintained.

If the desired target head for the variable speed pump is known it can simply be set and not optimized by Scheduler. If there is a large number of pumps to optimize the problem size can be cut down by simply setting the target head of some variable speed pumps and batteries and not including those as pumps to optimize. This minimizes the solution spacer of the optimization ensuring better results for the pumps that are optimized. If, however, a reasonable target head for the system is not known, then Scheduler can assist with determining what a reasonable head setting might be as well as the pump speed.

However, there is no guarantee that the "optimal" speeds determined by Darwin Scheduler will be better than simply trying to maintain a know head or flow in a standard variable speed simulation run. This is due to the fact that Scheduler looks at discrete speeds such as 0.8, 0.85, 0.9 while the simulation run may be able to find a better solution by running at 0.86759 which Scheduler would not be able to find. The primary advantage of using Scheduler is that it can consider multiple constraints while a standard simulation only has a single set point.

When a pump is selected to be optimized by Darwin Scheduler full control of that pump is given to Darwin Scheduler. The pump will ignore any VSP control properties and will not necessarily maintain target flows or heads. This is handled by setting constraints on pressures or flows. Be careful not to set the minimum and maximum constraint too close together, given the time step size and increment, or else it may not be possible to obtain a feasible solution.

When a pump is selected to be optimized by Darwin Scheduler full control of that pump is given to Darwin Scheduler. The pump will ignore any control actions applied to it.

When a pump is selected to be optimized by Darwin Scheduler full control of that pump is given to Darwin Scheduler. The pump will ignore any patterns applied to it.

Darwin Scheduler is able to optimize the operation of Variable Speed Pump Batteries by considering them as a lead pump with the specified number of lag pumps in parallel. In order for the solution that is exported by Darwin Scheduler to match up with Darwin Scheduler's simulated hydraulics and energy cost/use it must export a scenario that is functionally equivalent to the optimized schedule. Since Variable Speed Pump Battery elements are not designed to work with pump patterns, Darwin Scheduler exports these as single pumps with a pattern applied to replicate the optimized pump schedule. Correspondingly each lag pump will have its own pattern.

In this case one or more tanks is included in the objective elements list in Darwin Scheduler and Scheduler is accounting for the energy deficit or credit from the tank(s) filling or draining; ensure that the energy costs tool is also accounting for the energy credit/deficit due to tanks to verify Scheduler's calculated energy costs and/or energy usage. Filling a tank is essentially storing energy for later use while draining that tank uses stored energy.

This is because Darwin Scheduler allows the optimization to consider any pumps or tanks in the assessment of the objective value (energy use or energy cost) as opposed to just the elements included in the optimization process as decisions or constraints. This allows selective optimization of specific pumps whilst leaving others operating according to their control rules (or VSP settings), but factoring in the cost of all (or any number) of the pumps in the model, regardless of whether they are being optimized or not.

Using blanket constraints is the easiest way to de-rail the optimization by inadvertently including constraints that are impossible to meet such as the suction side nodes of pumps in pressure constraints. Since constraints are entered manually (using several convenient methods) a user is encouraged to first think about the constraints that are being added. For more information please see the "Darwin Scheduler Best Practices and Tips" topic.

There could be several reasons for this including:

1. The Scheduler constraints include an impossible to meet constraint such as a minimum required pressure that is on the suction side of a pump, or a required pressure near a tank with too low a level.
2. The Scheduler constraints include two or more inconsistent constraints. For example one junction may require a pressure of < 50 psi, whilst an adjacent junction might require > 50 psi. When there is high penalty associated with more than one constraint, check to see if the constraints are not mutually exclusive.
3. The schedule for optimization is not appropriate for the EPS being optimized. One example might be a 48 hour EPS run that is set up to optimize pump operation for the first 24 hours only, but requiring a high final tank level. Note that Scheduler optimized pumps are turned off outside of their optimized schedule.
4. The run has not been allowed to run sufficiently long enough for all constraints to be met by the evolved solutions.
5. If a tank is small relative to the time it takes to fill or drain it, it may consistently overshoot the maximum level or drop below the minimum. The time to fill or drain a tank should be much larger than the time step size.

Constraints have potentially been defined that are based on the control based pump schedule and are thus affording the optimization process no flexibility in being able to change the pumping schedule. Bear in mind that an energy use optimization is more constrained than energy cost in the sense that the optimization is not able to leverage variations in energy tariffs to find a better solution. For example, if in the base pump schedule a single pump is running all day to meet hydraulic criteria, surely there is little scope for saving energy costs in that context unless there is either flexibility in hydraulic criteria or other pumps that can be utilized.

There are a number of reasons for this, but the main reason is that in contrast to the other two Darwin tools (Calibrator and Designer) Scheduler has a higher computational overhead by virtue of the fact it simulates a full EPS run compared to just single steady state snapshots in Designer and Calibrator. For example a 24 hour EPS is a kin to running 24 Design Events in Designer or 24 Field Data Sets in Calibrator. Running a full EPS is necessary to properly evaluate a pump schedule since pump energy is used and volume changes occur over time, whereas Designer and Calibrator are more concerned with peak conditions. Then consider that for an optimization to complete, typically tens of thousands of trials are required. If a single EPS takes a full second to run, a Darwin Scheduler run will require several hours to complete. This makes running Darwin Scheduler over night on large models an attractive proposition.

For additional information on Darwin Scheduler performance and how to get the best out of Darwin Scheduler please see Best Practices and Tips.

Fitness is calculated as follows:

For an energy use optimization, fitness is calculated as the total energy use of the pump elements specified in the objective elements section for the duration of the full EPS plus the energy credit or deficit from the tanks specified in the objective elements section for the duration of the full EPS plus any penalties encountered. Tank energy credit is based on the average energy per volume pumped for the duration of the EPS. Fitness is in the units of energy (kWh).

For an energy cost optimization, fitness is calculated as the total energy cost of the pump elements specified in the objective elements section for the duration of the full EPS plus the energy cost credit or deficit from the tanks specified in the objective elements section for the duration of the full EPS, plus any penalties encountered. Tank energy cost credit is based on the average energy cost per volume pumped for the duration of the EPS. Fitness is in the units of cost ($).

For both optimization types note that a marginal value is added to the fitness of a solution based on the total number of pump starts that occur. This is applied independently and in addition to any user-defined pump start constraint and ensures that optimized solutions adopt less pump starts unless there is a significant benefit to having more pump starts.

All energy use calculations factor in pump efficiency and pump motor efficiency.

All energy cost calculations factor in specified energy tariffs.

Darwin Scheduler doesnot factor in peak demand charge.

This simply means that the solution (or current best solution) does not meet all of the hydraulic constraints; the value itself is the penalty applied due to constraint violations. Leaving a run to execute for longer will most likely reduce violation to 0.0 meaning a feasible solution has been found. The term "feasible" is used to describe a solution that meets all the specified hydraulic constraints, however, through proper review and engineering judgment a non-feasible solution (one with violation greater than 0.0) may also be deemed to be feasible in practical terms.

The calculation of violation varies depending on the constraint type as follows:

Pressure Constraints:

Violation =

Where Pi is the average absolute pressure violation at constraint Node i, and PFp is the pressure penalty factor.

Velocity Constraints:

Violation =

Where Vi is the average absolute velocity violation at constraint Pipe i, and PFv is the velocity penalty factor.

Pump Start Constraints:

Violation =

Where Pi is the average absolute pump start violation at constraint Pump i, and PFps is the pump start penalty factor. Note that violation for pump starts is calculated in a cumulative sense so that the rolling number of pump starts is used to calculate the violation at each time. This makes solutions that exceed their maximum pump starts early in the optimized schedule less desirable compared to ones that may only fail their constraint near the end of the schedule.

Tank Final Level Constraints:

Violation =

Where LV is the final level violation, and PFt is the tank final level penalty factor.

Most users will not have to concern themselves with the adjustment of these parameters and reasonable defaults have been set as defaults for normal use. Advanced users or users that are particularly interested in optimization may wish to play with these parameters to assess their effect on the optimization process. Darwin Scheduler will not accept values for any parameter that are considered to be detrimental to the operation of the engine as a whole, however, such values still might not be recommended to use. To that end we provide some recommended ranges of values for each parameter.

Genetic Algorithm Parameters

Population Size: 50-200. Sometimes as high as 1000+

Elite Population Size: 10-20

Number of Cross Over Points: 2-10 or 2-10% of the problem length

Probability of Cross Over: 90-100%

Probability of Mutation: 1-2%

Probability of Creeping Mutation: 0-1%

Probability of Creeping Down: For this problem type higher than 50%

Probability of Cut: 1-2%

Probability of Splice: 90-95%

Probability of Elite Mate: 0-1%

Stopping Criteria

Maximum Generations: Typically 500 - 2000

Maximum Eras: Typically 6-12

Maximum Trials: Typically 50000 - 200000 or higher (the larger the population size used, the larger this should be)

Penalty Factors

These factors are used to weight different constraint types against each other, but primarily to guide the optimization process towards areas of the solution space that contain solutions that do not violate constraints. These factors should rarely require manipulation.

Pressure Penalty: 0.5 - 2.0

Velocity Penalty: 0.5 - 2.0

Pump Starts Penalty: 5 - 20

Third party research suggests that Fast Messy Genetic Algorithms are better at finding near optimal solutions to complex problems than their Simple Genetic Algorithm predecessors and as such Darwin Calibrator and Darwin Designer both employ a type of Fast Messy Genetic Algorithm. Darwin Scheduler makes use of a newly developed Genetic Algorithm component and it was little additional work for us to expose both Genetic Algorithm types to users instead of just the one so we did. This will enable those who are interested in optimization to experiment using both types of algorithm.

As part of the messy genetic algorithm process prior to the creation of a new generation of trial solutions, parents must be selected for the new generation. Owing to the nature of the messy GA solution representation suitable parent chromosomes must be compared against other chromosomes with a certain similarity measure. The process by which chromosomes are found that meet the similarity measure is called genic thresholding and sometimes this can take a little while to execute, meaning CPU time is spent for a short period on the genic thresholding process as opposed to evaluating trial solutions. The simple genetic algorithm does not perform genic thresholding and therefore does not have this delay. Note, however, that the run-time required for genetic algorithm processes pales in significance compared to the time required to evaluate trial solutions, even for the Fast Messy Genetic Algorithm.

The reason for this is that in order for various things to work correctly (such as the resume feature) Scheduler will complete the current generation that it is evaluating before returning control to the user. This is indicated on the Optimization Progress dialog by the Stop button becoming disabled and the Optimization Progress dialog status showing "Stopping...". Depending on the population size of the run and the time taken for a single trial this may represent several minutes, so please be patient during this process.

Darwin Scheduler stores its results in a proprietary binary file format with a *.dsb (Darwin Scheduler Binary) extension. When the model is saved any Darwin Scheduler results files will be saved too.

Darwin Scheduler's user interface provides summaries of the optimized pump schedules and of hydraulic performance, however, the best way to view Darwin Scheduler results is to export the optimized scenario to the model and analyze results by leveraging the full suite of results visualization tools available in the main application. Of particular value will be the Scenario Energy Cost Manager for a detailed break down of energy use and cost.

The answer to this question lies in the fact that Darwin Scheduler simulates an entire EPS run as opposed to a set of steady state snapshots like Darwin Calibrator or Darwin Designer. In those latter two tools it is necessary for a user to be able to specify boundary conditions (such as valve settings and tank levels) that define the hydraulic conditions that apply to the associated hydraulic snapshot. For example, if the snapshot is for 7am, tank levels etc will be specified for that time. This, however, is unnecessary for Darwin Scheduler since it simulates a full EPS run and therefore is able to calculate the boundary conditions at each time in the EPS run. To that end Darwin Scheduler's model input is completely acquired from the scenario being optimized. If it is necessary to consider additional demands or make other modifications to the hydraulic model before running an optimization, do so using the main application's standard scenario and alternative management tools, then select the modified scenario as the scenario to optimize in Darwin Scheduler.